r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Note that the opposite of this PR exists at #105296

Not sure in which sense that is the "opposite". I think having these APIs you propose is a good idea no matter what we do with align_to. But I also think having those APIs does not stop us from removing a footgun in align_to if we don't have sufficient motivation to keep the footgun.

But I also think having those APIs does not stop us from removing a footgun in align_to if we don't have sufficient motivation to keep the footgun.

those were only ever added to support making str::from_utf8 const at some point. That was their original motivation. If we close the door for that, it'll just mean we have to add the same function, but fallible, again.

I guess public usage of the functions does show what people want out of these APIs, so 🤷 let's just do it and figure things out when we're ready to make more stuff const

those were only ever added to support making str::from_utf8 const at some point. That was their original motivation. If we close the door for that, it'll just mean we have to add the same function, but fallible, again.

We're not closing the door on that though. from_utf8 can use align_offset and it will be correct

• at run-time, for obvious reasons
• at compile-time, because from_utf8 is written in a way to be robust to align_offset failing due to compile-time constraints

We discussed this in the libs-api meeting, and those present were happy with this change.

@rfcbot merge

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

With my lang hat on:

If I'm understanding correctly, these can differ at compile time precisely because the concept of addresses and them having alignment isn't the same at compile-time and runtime. That seems fine. We will still have options at compile-time; for instance, if we want to track the concept of "sufficiently aligned" at compile time, we could decide to do so in an abstract way.

If I'm understanding correctly, these can differ at compile time precisely because the concept of addresses and them having alignment isn't the same at compile-time and runtime.

Yes. The only time compile-time would give a "weird" answer is when the information required to give the expected answer is inherently unavailable at compile-time.

We will still have options at compile-time; for instance, if we want to track the concept of "sufficiently aligned" at compile time, we could decide to do so in an abstract way.

I think that might be tricky, e.g. if one crate declares a [u8; N] buffer stored somewhere then even tracking abstract alignment means downstream crates could be adding alignment constraints to that, e.g. deciding that it must be 4-aligned. I also don't think we actually want align_to to change the alignment of these static global objects.

Ah, align_to isn't const fn. Saying it won't be, and thus we can make strict promises about that function makes good sense to me, given all the complaints about it.

We can add a different function for const fn later if really needed.

@rustbot labels -I-lang-nominated

We discussed this in the lang call on 2024-03-13 and agreed that we were OK with this having been merged and the consequences of that noted in the original nomination.

Sorry, I hadn't realized the T-lang discussion was still open when this got approved.